Multi-factor authentication system and method

ABSTRACT

To authorize a client device to access a secure resource hosted on a web server, the present methods and systems may provide executable instructions including a challenge token to the client device, which, in turn, may cause the client device to provide executable instructions, including the challenge token, to a mobile client device via a persona area network. The executable instructions provided to the mobile client device may request the mobile client device to return a verification token. The mobile client device may compare the provided challenge token to a challenge token stored locally. If the challenge tokens match, the mobile client device may provide a verification token to the client device via the personal area network, which may in turn provide the verification token to the web server. The web server may compare the verification token provided by the client device to a verification token provided by the present methods and systems. If the verification tokens match, the web server may authorize the access to the secure resource.

FIELD

The present disclosure relates to network security and moreparticularly, to multifactor authentication.

BACKGROUND

User authorization may be performed with the following methods.

Users provide their credentials to a web server with a username andpassword as credentials. The credentials are encrypted before being sentover the network to prevent interception.

Once the user has logged into the web server, the web server may returna secure HTTP cookie (“secure cookie”), which is stored on the user'scomputer, and used as secondary authorization.

When the user logs into a web server, the web server can send a randomnumber to their phone, which the user sends back in addition to theirusername and password as a one-time credential.

The user can use an external device which has a time-based shared secretkey with the web server, which the user enters in addition to theirusername and password as a one-time credential.

The user can provide additional credentials, such as a smartcard orthumbprint (or other biometric identifier) in addition to their usernameand password.

However, if the user receives a random number from the website on theirphone, they have to activate their phone, and enter the number correctlyon the web page.

Likewise, if an HTTP cookie is stored on the user's computer, it can beretrieved by an attacker who has access to the computer, and does notprovide additional authentication if the user logs into a differentcomputer.

Also, if the user is required to use their thumbprint, once it isobtained by an attacker, he cannot change it like a password.

Additionally, smartcards require specialized hardware on the computer.

Furthermore, if a time-based secret key is obtained from the website byan attacker, he can use it to impersonate the user.

In the case of biometric authentication and TOTP tokens, if a hackerbreaks into the authorization server, they can impersonate any of itsusers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a network topology of an exemplaryclient/server-based identity verification management (“IVM”) system inaccordance with various embodiments of the present methods and systems.

FIG. 2 illustrates several components of an exemplary client device inaccordance with various embodiments of the present methods and systems.

FIG. 3 illustrates several components of an exemplary server inaccordance with various embodiments of the present methods and systems.

FIG. 4 illustrates a first exemplary series of communications betweenvarious devices in accordance with various embodiments of the presentmethods and systems.

FIG. 5 illustrates a second exemplary series of communications betweenvarious devices in accordance with various embodiments of the presentmethods and systems.

FIG. 6 illustrates a block diagram of an exemplary local IVM data updateroutine in accordance with various embodiments of the present methodsand systems.

FIG. 7 illustrates a block diagram of an exemplary remote IVM dataupdate sub-routine in accordance with various embodiments of the presentmethods and systems.

FIG. 8 illustrates a block diagram of an exemplary secure access routinein accordance with various embodiments of the present methods andsystems.

FIG. 9A-B illustrate a block diagram of an exemplary identityverification sub-routine in accordance with various embodiments of thepresent methods and systems.

FIG. 10 illustrates a block diagram of an exemplary remote IVMsub-routine in accordance with various embodiments of the presentmethods and systems.

FIG. 11 illustrates a block diagram of an exemplary identityverification script in accordance with various embodiments of thepresent methods and systems.

FIG. 12 illustrates a block diagram of an exemplary identityverification sub-script in accordance with various embodiments of thepresent methods and systems.

DETAILED DESCRIPTION

The detailed description that follows is represented largely in terms ofprocesses and symbolic representations of operations by conventionalcomputer components, including a processor, memory storage devices forthe processor, connected display devices and input devices. Furthermore,these processes and operations may utilize conventional computercomponents in a heterogeneous distributed computing environment,including remote file servers, computer servers, and/or memory storagedevices. Each of these conventional distributed computing components isaccessible by the processor via a communication network, which mayinclude, but is not limited to, the Internet.

The phrases “in one embodiment,” “in various embodiments,” “in someembodiments,” and the like are used repeatedly. Such phrases do notnecessarily refer to the same embodiment. The terms “comprising,”“having,” and “including” are synonymous, unless the context dictatesotherwise.

Reference is now made in detail to the description of certain exemplaryaspects of various embodiments of the present methods and systems withreference to the accompanying Drawings. There is no intent to limit thescope of the systems, methods, and the like as are defined in the Claimswhich follow this Description to the particular embodiments describedherein. On the contrary, the intent is to provide sufficient examples inorder to enable any person skilled in the art to which the presentSpecification pertains to make and use all alternatives, modifications,and equivalents of the present systems and methods. In alternateembodiments, additional devices, or combinations of illustrated devices,may be added to, or combined, without limiting the scope to theembodiments disclosed herein. For example, the embodiments set forthbelow are primarily described in the context of a general-purposecomputer in data communication with a “smartphone” via a proximal (i.e.relatively short range) wireless networking protocol such as Bluetooth.However, these embodiments are exemplary and the scope of the presentmethods and systems are in no way limited by the characteristics andcomponents of the specific examples described

An Exemplary Client/Server-Based Identity Verification Management System

FIG. 1 illustrates a network topology of an exemplaryclient/server-based identity verification management (“IVM”) system 100in accordance with various embodiments of the present methods andsystems.

An arbitrary client device 200A, an identity verification management(“IVM”) server 300A, and a web server 300B may each be in datacommunication with a network 103. In various embodiments, network 103may include the Internet, one or more local area networks (“LANs”), oneor more wide area networks (“WANs”), cellular data networks, and/orother data networks. Network 103 may, at various points, be a wiredand/or wireless network.

A mobile client device 200B may also be in data communication withnetwork 103. Arbitrary client device 200A and mobile client device 200Bmay also be in data communication with one another via a personal areanetwork (“PAN”) 105.

PAN 105 may, for example, be implemented according to a knowncommunication standard such as Bluetooth, WiFi, Ethernet, or the like.Unlike data communication via network 103, data communication via PAN105 may require arbitrary client device 200A and mobile client device200B to be in relative physical proximity to one another, as indicatedby physically proximate area 108.

IVM server 300A may be in data communication with an authentication datastore 110. The functionality of IVM server 300A is described in moredetail below.

Web server 300B may be operated by a commercial (or non-commercial)enterprise. In some embodiments, IVM server 300A may also be operated bythe commercial enterprise. In other embodiments, authenticationverification server 300A may operate cooperatively with, butindependently of, the commercial enterprise.

In these and other embodiments, arbitrary client device 200A may be acomputing device having an arbitrary form factor including a generalpurpose computer (including “laptop,” “notebook,” “tablet” computers, orthe like); a mobile phone; a wearable computing device (includingwatches, glasses, or the like); a motor vehicle head unit; or the like.For simplified exemplary purposes, arbitrary client device 200A isdepicted as a laptop computer.

In these and other embodiments, mobile client device 200B may be amobile computing device having a form factor including a mobile phone;wearable computing device (including watches, glasses, or the like). Asis explained in more detail below, second client device 300 may be aportable or mobile device that is carried (or worn) by a primary user.For simplified exemplary purposes, first client device 200 is depictedas a laptop computer. The primary functional components of an exemplary,form-factor-independent first client device 200 are described below inreference to FIG. 2.

As is explained in more detail below, arbitrary client device 200A andmobile client device 200B may both be associated with a common useridentity (not shown) corresponding to an authorized user of thecommercial enterprise. As relevant to the present methods and systems,the primary distinction between arbitrary client device 200A and mobileclient device 200B is that arbitrary client device 200A may have arelatively weak association with the common user identity, e.g. the useridentity may be one of many users of the arbitrary client device, whilemobile client device 200B may have a relatively strong association withthe user identity, e.g. the user identity may be the primary user of themobile client device. The primary functional components of an exemplary,form-factor-independent client device 200 are described below inreference to FIG. 2.

In various embodiments, IVM server 300A and web server 300B may benetworked computing devices generally capable of accepting requests overnetwork 103, e.g. from arbitrary client device 200A, mobile clientdevice 200B, each other, and/or other networked computing devices (notshown), and providing responses accordingly. The primary functionalcomponents of an exemplary server 300, such as IVM server 300A and webserver 300B, are described below in reference to FIG. 3.

Exemplary Client Device

FIG. 2 illustrates several components of an exemplary client device 200,such as either of arbitrary client device 200A and mobile client device200B. However, the present methods and systems do not depend on anyparticular internal configuration or functionality of a client device.

As shown in FIG. 2, exemplary client device 200 includes a centralprocessing unit 203 in data communication with memory 205 via a bus 208.Central processing unit 203 is an electronic circuit designed to obtaininstruction of a computer program, e.g. from memory 205, carry out theinstructions, e.g. by performing the arithmetic, logical, control andinput/output (I/O) operations specified by the program's instructions.Memory 205 generally comprises some or all of: random access memory(RAM), read-only memory (ROM), and/or a permanent mass storage device,such as a disk drive, flash memory, or the like. Bus 208 is acommunication system that transfers data between components withinclient device 200, and encompasses any related hardware components(wire, optical fiber, etc.) and software, including communicationprotocols; the data communications between various components of clientdevice 200 may be accomplished by wired and/or wireless connections.

Client device 200 may also include a network interface 210 forconnecting to a network such as network 103; one or more optional userinput device(s) 213, e.g. an alphanumeric keyboard, keypad, a mouse orother pointing device, a touchscreen, and/or a microphone (or a userinput port for connecting an external user input device); optionaldisplay 215 (or a display input port for connecting to an externaldisplay device); and the like, all interconnected, along with thenetwork interface 210, to central processing unit 203 and memory 205 viabus 208. Client device 200 may also include a personal area networkinterface 218 for connecting to a personal area network, such as PAN108. In some embodiments, a client device 200 may include many morecomponents than those shown in FIG. 2, such as a global positioningmodule. However, it is not necessary that these, generally conventional,components be shown in order to disclose an illustrative embodiment.

Memory 205 of exemplary client device 200 may store program code,executable by central processing unit 203, corresponding to an operatingsystem 223, as well as program code corresponding to various softwareapplications, such as a browser application 225 and other softwareapplications (not shown). Operating system 223 and such various softwareapplications may be loaded into memory 205 via network interface 210 orvia a computer readable storage medium 230, such as a hard-disk drive, asolid-state drive, an optical disc, a removable memory card, and/or thelike.

In operation, operating system 223 manages the hardware and softwareresources of client device 200 and provides common services and memoryallocation for various software applications, such as browserapplication 225. For hardware functions such as network communicationsvia network interface 210 and personal area network interface 218,receiving data via input 213, outputting data via optional display 215,and allocation of memory 205 for various software applications, such asbrowser application 225, operating system 223 acts as an intermediarybetween software executing on the client device and the device'shardware.

For example, operating system 223 may cause an iconic representation ofavailable software applications, such as browser application 225, to bepresented via display 215. If client device 200 obtains an indicationvia user input 213, e.g. from a user of the client device, a desire touse a specific software application, operating system 223 mayinstantiate a corresponding application process (not shown), i.e. causecentral processing unit 203 to begin executing the executableinstructions of the application and allocate a portion of memory 205 forits use.

Browser application 225 may be a software application for retrieving,processing, presenting, and traversing information resources on anetwork, such as network 108. Although browser application 225 may beprimarily intended to use the World Wide Web, it may also be used toaccess information resources provided by remote servers in privatenetworks. An information resource may be a web page, an image, a video,or other piece of content and may be identified by a Uniform ResourceIdentifier (URI/URL) on network 108. An information resource may alsoprovide browser application 225 executable program code for webapplications, i.e. a software application that runs in and is renderedby browser application 225.

In the case of a web application, browser application 225 may act as anintermediary between a software service operating on a remote server,such as IVM server 300A and/or web server 300B, and the operating system223.

Although an exemplary client device 200 has been described with hardwarecomponents that generally conforms to conventional general purposecomputing devices, a client device may be any of a great number ofdevices capable of communicating with network 103 and executinginstructions for performing either 3P customer client application 228Aand/or 3P-SP client application 228B.

Exemplary Server

FIG. 3 illustrates several components of an exemplary server 300, suchas IVM server 300A and web server 300B. However, the present methods andsystems do not depend on any particular internal configuration orfunctionality of a server.

As shown in FIG. 3, exemplary server 300 includes a central processingunit 303 in data communication with memory 305 via a bus 308. Centralprocessing unit 303 is an electronic circuit designed to carry outinstructions of a computer program, e.g. obtained from memory 305, byperforming the basic arithmetic, logical, control and input/output (I/O)operations specified by the program's instructions. Memory 305 maygenerally include some or all of random access memory (RAM), read-onlymemory (ROM), and/or a permanent mass storage device, such as a diskdrive, flash memory, or the like. Bus 308 is a communication system thattransfers data between components within exemplary server 300, andincludes any related hardware components (wire, optical fiber, etc.) andsoftware, including communication protocols.

Server 300 may also include a network interface 310 for connecting to anetwork such as network 103, one or more optional user input device(s)313, e.g. an alphanumeric keyboard, keypad, a mouse or other pointingdevice, a touchscreen, and/or a microphone, (or a user input port forconnecting an external user input device) and/or an optional display 315(or a display port for connecting an external display device), bothinterconnected along with the network interface 310 via bus 308. In someembodiments, server 300 may include many more components than thoseshown in FIG. 3. However, it is not necessary that all of thesegenerally conventional components be shown in order to disclose anillustrative embodiment.

Memory 305 may store an operating system 323 and program code forvarious software services 323. For example, IVM server 300A may includeexecutable instructions for performing IVM service 323A (indicated bydotted lines) and web server 300B may include executable instructionsfor performing a merchant service 323B (indicated by dotted lines).

Program code for these and other such software services (not shown) maybe loaded into memory 305 from a non-transient computer readable storagemedium 330 using a drive mechanism (not shown) associated with thenon-transient computer readable storage medium, such as, but not limitedto, a DVD/CD-ROM drive, memory card, or the like. Software componentsmay also be loaded into memory 305 via the network interface 310. Server300 may also communicate via bus 308 with a database (not shown), suchas IVM data store 105, or other local or remote data store.

In operation, operating system 323 manages the hardware and softwareresources of server 300 and provides common services and memoryallocation for various software services, such as IVM service 323A ormerchant service 323B. For hardware functions, such as networkcommunications via network interface 310 and allocation of memory 305for various software services, such as IVM service 323A, operatingsystem 323 may act as an intermediary between software executing onserver 300 and the server's hardware.

Although an exemplary server 300 has been described having hardwarecomponents that generally conform to a conventional general purposecomputing device, a server may be any of a great number of devicescapable of communicating with network 103 and executing instructions forperforming IVM service 323A and/or merchant service 323B.

In some embodiments, a server 300 may comprise one or more replicatedand/or distributed physical or logical devices. In some embodiments, IVMserver 300A and web server 300B may be embodied by the same physicaldevice. The present methods and systems do not depend on any particularinternal configuration of server 300.

Exemplary User Identity Verification System and Methods

Referring again to FIG. 1, an application, such as browser application225A, operating on arbitrary client device 200A may provide a log inrequest, or another type of secure access request, specifying a useridentifier to a service, such as merchant service 325B, operating on webserver 300B. In accordance with various embodiments, the present methodsand systems may authorize the requested data communication session byverifying that another client device that is also associated with thespecified user identifier, such as mobile client device 200B, is inphysical proximity of the arbitrary client device.

Some embodiments may utilize three types of tokens: verification tokens,challenge tokens, and manual verification tokens. As is explained inmore detail below, verification tokens are used to validate the sessionunder “normal” circumstances; challenge tokens are sent from arbitraryclient device 200A to mobile client device 200B; and manual verificationtokens are sent from mobile client device 200B to the arbitrary clientdevice 200A if the does not have a secure cookie from the website. Thesetokens may be provided to mobile client device 200B from IVM server 300Ain advance of an authorization request.

IVM server 300A may also send an encryption key to web server and mobileclient device 200B, which may be used to encrypt the session between thearbitrary client device 200A and the web server.

In some embodiments, IVM server 300A may provide verification,challenge, and manual verification tokens and session encryption keys tomobile client device 200B in advance of an authorization request. Thekeys and tokens are sent with an authorizing domain identifier, and anexpiration date. Such a “pre-synching” operation allows mobile clientdevice 200B to authorize a data communication session regardless ofwhether the mobile client device is in data communication with IVMserver 300A at the time of the authorization request. In such anembodiment, the tokens and keys may be periodically refreshed/updatedwhile mobile client device is in data communication with IVM server300A.

Upon obtaining the secure access request from arbitrary client device200A, web server 300B may make an identity verification request to IVMserver 300A. The identity verification request may include a unique useridentifier. IVM server 300A may then look up an identity verificationdata structure associated with the provided unique user identifier.

An identity verification data structure associated with a unique useridentifier may include a data communication address associated with amobile client device, data records corresponding to tokens that may havebeen previously provided to the mobile client device and associatedtoken expiration dates, data records corresponding to previous datacommunication session authorizations/authorization attempts, and thelike.

Using information obtained from the identity verification datastructure, IVM server 300A may (1) select a token set and apublic/private encryption key pair for the current data communicationsession authorization, (2) provide a secure access response to webserver 300B including unencrypted versions of the selected token set andthe public key from the selected key pair and, if necessary, (3) providea secure session client authorization request to the mobile clientdevice including the token set and the private key from the selected keypair.

Merchant service 325B may provide a log-in page to browser application225A responsive to the secure access request. The log-in page mayinclude a request for a secure cookie (or the like) associated with aprevious secure data communication session between merchant service 325Band browser application 225A. (A secure cookie is a cookie that may onlybe read over a secure connection by a server whose domain matches thedomain that the secure cookie was written with.)

If browser application 225A provides the requested secure cookie,indicating a previous secure data communication session between thebrowser application and merchant service 325B, the merchant service mayprovide executable instructions including the challenge token to browserapplication 225A, which, in turn, may cause browser application 225A toprovide executable instructions, including the challenge token obtainedfrom IVM service 325A, to mobile client device 200B via PAN 105. Theexecutable instructions provided to mobile client device 200B mayrequest browser application 225B to return the verification tokenobtained from IVM service 325A. Browser application 225B may compare thechallenge token provided by merchant service 325B via browserapplication 225A to the challenge token provided by IVM service 325A. Ifthe challenge tokens match, browser application 225B may provide theunencrypted verification token provided by IVM service 325A to browserapplication 225B via PAN 105, which may in turn provide the verificationtoken to merchant service 325B via network 103. Merchant service 325Bmay compare the verification token provided by browser application 225Bvia browser application 225A to the verification token provided by IVMservice 325A. If the verification tokens match, merchant service 325Bmay authorize the requested data communication session.

In some embodiments, mobile client device 200A is provided with aprivate encryption key and web server 300B is provided with acorresponding public encryption key. Mobile client device 200A providesthe private key to arbitrary client device 200B, and the arbitraryclient device and web server 300B may use the private/public encryptionkey pair encrypt/decrypt communications for the data communicationsession.

If browser application 225A does not provide the requested securecookie, merchant service 325B may provide an alternate set of executableinstructions to browser application 225A, which, in turn, may causebrowser application 225A to provide executable instructions to mobileclient device 200B via PAN 105. The executable instructions provided tomobile client device 200B may (1) cause the mobile client device toprovide an authentication prompt, e.g. via display 215B, identifying theURI of merchant service 325B and (2) require a manual response to theauthentication prompt, e.g. obtained via user input 213. Upon obtainingthe manual response, mobile client device 200B may return the manualverification token provided by IVM service 325A to browser application225A via PAN 105. Browser application 225A may provide the manualverification token to merchant service 325B via network 103. Merchantservice 325B may compare the manual verification token provided bybrowser application 225B via browser application 225A to the manualverification token provided by IVM service 325A. If the manualverification tokens match, merchant service 325B may authorize therequested data communication session.

A First Exemplary Series of Communications

FIG. 4 illustrates a first exemplary series of communications 400between mobile client device 200B and IVM server 300A corresponding toan optional “pre-synching” of IVM data between the mobile client deviceand the IVM server. During the pre-synching process, mobile clientdevice 200B may be communicating directly with IVM server 300A, e.g. viaa network such as network 103.

Referring first to FIG. 4, mobile client device 200B may process 403 aninternal IVM data update request. For example, mobile client device 200Bmay be configured to generate an internal IVM data update request at aregular interval.

Mobile client device may provide an IVM data update request 405 to IVMserver 300A. The IVM data update request may include an identifier, suchas a user identifier and/or a mobile client device identifier.

IVM server 300A may process 408 IVM data update request 405. Forexample, IVM server 300A may search authentication data store 110 for anidentity verification data structure associated with the identifierprovided in the IVM data update request.

IVM server 300A may provide an IVM data update response 410 to mobileclient device 200B. IVM data update response 410 may include one or moretoken sets (each token set may include a verification token, a manualverification token, and a challenge token) and expiration date(s) andprivate encryption key(s) associated with the token sets.

Mobile client device 200B may process 413 IVM data update response 410.For example, mobile client device 200B may store the token sets andassociated expiration dates and/or encryption keys in memory 205.

A Second Exemplary Series of Communications

FIG. 5 illustrates a second exemplary series of communications 500between mobile client device 200B, IVM server 300A, arbitrary clientdevice 200A, and web server 200B in accordance with various embodimentsof an IVM system, such as the IVM systems described above, and relatingto providing user identity verification services. During secondexemplary series of communications 500, mobile client device 200B may becommunicating with IVM server 300A via network 103 and with arbitraryclient device 200A via PAN 105.

Arbitrary client device 200A may process 503 an access request. Forexample, arbitrary client device 200A may obtain an indication directingit to access a URI associated with web server 300B.

Arbitrary client device 200A may then provide a secure access request505 to web server 300B.

Web server 300B may process 508 secure access request 505 and provide anidentity verification request 510 to IVM server 300A.

IVM server 300A may process 513 identity verification request 510 andprovide an IVM data update 515 to mobile client device 200B and anidentity verification response 518 to web server 300B. IVM data update515 may include a token set and a private encryption key. Identityverification response 518 may include the token set and the publicencryption key corresponding to the private encryption key provided inIVM data update 515.

Mobile client device 200B may process 520 IVM data update 515, forexample by storing the token set and private key in memory 205B.

Web server 300B may process 523 identity verification response 518, forexample, by encrypting the challenge token using the public encryptionkey and providing a challenge request 525 to arbitrary client device200A. Challenge request 525 may request a secure cookie from arbitraryclient device 200A.

Arbitrary client device 200A may process 528 challenge request 525 andprovide a proximate challenge request 530 to mobile client device 200B.Proximate challenge request may include the encrypted challenge tokenand is provided over PAN 105.

Mobile client device 200B may process 533 proximate challenge request530. For example, mobile client device may: decrypt the encryptedchallenge token using the private encryption key; compare the decryptedchallenge token to the challenge token obtained from IVM server 300A;and, if the challenge tokens match, encrypt the verification token (orthe manual verification token) using the private encryption key andprovide a proximate challenge response 535 to arbitrary client device200A including the encrypted verification token (or the encrypted manualverification token). Proximate challenge response 535 is provided overPAN 105.

Arbitrary client device 200A may process 538 proximate challengeresponse 535 and provide a corresponding challenge response 540 to webserver 300B.

Web server 300B may process 543 challenge response 540. For example, webserver 300B may: decrypt the verification token (or the manualverification token) using the public encryption key; compare thedecrypted verification token (or manual verification token to theverification token (or manual verification token) obtained from IVMserver 300A; and, if the verification tokens match, provide anaffirmative secure access response 545 to arbitrary client device 200A.

Local IVM Data Update Routine

FIG. 6 illustrates an exemplary local IVM data update routine 600. LocalIVM data update routine 600 may represent a portion of the functionalityof an application being executed by central processing unit 203B ofmobile client device 200B in cooperation with various other hardware andsoftware components of the mobile client device.

Local IVM data update routine 600 may obtain internal IVM data checkrequest at execution block 603.

Local IVM data update routine 600 may obtain a local data expirationdate at execution block 05.

At decision block 608, if the local IVM data is expired, then local IVMdata update routine 600 may call remote IVM data update remote IVM dataupdate sub-routine 700, described below in reference to FIG. 7 and whichmay return new/updated IVM data, including one or more token sets and/ora private encryption key; otherwise local IVM data update routine 600may proceed to return block 699.

At decision block 613, if updated IVM data has been obtained from remoteIVM data update sub-routine 700, then local IVM data update routine 600may proceed to execution block 615; otherwise local IVM data updateroutine 600 may proceed to execution block 620.

Local IVM data update routine 600 may update the internal IVM datastructures updated IVM data obtained from remote IVM data update remoteIVM data update sub-routine 700 at execution block 615.

Local IVM data update routine 600 may provide in IVM update errormessage at execution block 620.

Local IVM data update routine 600 may terminate at return block 699.

Remote IVM Data Update Sub-Routine

FIG. 7 illustrates an exemplary remote IVM data update sub-routine 700.Remote IVM data update sub-routine 700 may represent a portion of thefunctionality of IVM service 325A being executed by central processingunit 303A of IVM server 300A in cooperation with various other hardwareand software components of the present methods and symptoms.

Remote IVM data update sub-routine 700 may obtain in IVM data updaterequest at execution block 703.

Remote IVM data update sub-routine 700 may verify a user identifierprovided in the IVM update request at execution block 705.

At decision block 708, if a new private key is requested in the IVMupdate request, then remote IVM data update sub-routine 700 may proceedto execution block 710; otherwise, remote IVM data update sub-routine700 may proceed to execution block 715.

Remote IVM data update sub-routine 700 may generate a new private/publickey pair at execution block 710.

Remote IVM data update sub-routine 700 may associate the generated keypair with the user identifier at execution block 712.

Remote IVM data update sub-routine 700 may add the generated private keyto a response message at execution block 713.

Remote IVM data update sub-routine 700 may generate one or more newtoken sets at execution block 715.

Remote IVM data update sub-routine 700 may associate the generated tokensets with the user identifier at execution block 716.

Remote IVM data update sub-routine 700 may add the generated challengesto the response message at execution block 718.

Remote IVM data update sub-routine 700 may terminate by returning theresponse message at execution block 799.

Exemplary Secure Access Routine

FIG. 8 illustrates an exemplary secure access routine 800. Secure accessroutine 800 may represent a portion of the functionality of merchantservice 325B being executed by central processing unit 303B of webserver 300B in cooperation with various other hardware and softwarecomponents of the present methods and symptoms.

Secure access routine 800 may obtain a secure access request atexecution block 903.

Secure access routine 800 may call an identity verification sub-routine900, described below with reference to FIG. 9.

At decision block 804, if identity verification sub-routine 900 returnsa true value, then secure access routine 800 may permit the requestedaccess at execution block 805; otherwise secure access routine 800 maydeny the requested access at execution block 808.

Secure access routine 800 may terminate at termination block 899.

Exemplary Identity Verification Sub-Routine

FIGS. 9A-B illustrate an exemplary identity verification sub-routine900. Identity verification sub-routine 900 may represent a portion ofthe functionality of merchant service 325B.

Referring to FIG. 9A, identity verification sub-routine 900 may obtainan identity verification request at execution block 903.

Identity verification sub-routine 900 may obtain a user identifier atdecision block 905.

Identity verification sub-routine 900 may request a secure cookie fromarbitrary client device 200A at execution block 908.

At decision block 910, if a secure cookie is obtained from arbitraryclient device 200A, then identity verification sub-routine 900 mayproceed to execution block 915; otherwise identity verificationsub-routine 900 may proceed to decision block 913.

At decision block 913, if a predefined timeout value for obtaining asecure cookie has been exceeded, then identity verification sub-routine900 may proceed to execution block 918; otherwise identity verificationsub-routine 900 may loop back to decision block 910.

Identity verification sub-routine 900 may set a manual verification flagvalue to false at execution block 915.

Identity verification sub-routine 900 may set the manual verificationflag value to true at execution block 918.

Identity verification sub-routine 900 may call a remote IVM sub-routine1000, described below with reference to FIG. 10. Identity verificationsub-routine 900 may provide remote IVM sub-routine 1000 with the manualverification flag value. As is described below, IVM sub-routine 1000 mayreturn an unencrypted token set, a public encryption key, and anidentity verification script. The challenge token in the token set mayhave a manual verification value set according to the corresponding tothe manual verification flag provided to IVM sub-routine 1000.

Identity verification sub-routine 900 may encrypt the challenge tokenwith the public encryption key at execution block 920.

Referring now to FIG. 9B, identity verification sub-routine 900 mayprovide the identity verification script and the encrypted challengetoken to arbitrary client device 200A at execution block 923.

At decision block 925, if a token is obtained from arbitrary clientdevice 200A in response to the identity verification script, thenidentity verification sub-routine 900 may proceed to execution block930; otherwise identity verification sub-routine 900 may proceed todecision block 928.

At decision block 928, if a predefined timeout value for obtaining atoken from arbitrary client device 200A in response to the identityverification script has been exceeded, then identity verificationsub-routine 900 may proceed to return block 997; otherwise identityverification sub-routine 900 may loop back to decision block 920.

Identity verification sub-routine 900 may decrypt the token obtainedfrom arbitrary client device 200A using the public-key at executionblock 930.

At decision block 933, if the decrypted token matches either theunencrypted verification token or the unencrypted manual verificationtoken, then identity verification sub-routine 900 may proceed toexecution block 998; otherwise identity verification sub-routine 900 mayproceed to execution block 999.

Exemplary Remote IVM Sub-Routine

FIG. 10 illustrates an exemplary remote IVM sub-routine 1000. Remote IVMsub-routine 1000 may represent a portion of the functionality of IVMservice 325A.

IVM sub-routine 1000 may obtain IVM ID verification request at executionblock 1003.

IVM sub-routine 1000 may look up a token status corresponding to a useridentifier provided in the IVM ID verification request at executionblock 1010.

At decision block 1013, if at least one non-expired token set isassociated with the user identifier, then IVM sub-routine 1000 mayproceed to execution block 1015; otherwise IVM sub-routine 1000 may callIVM data update sub-routine 700, described above, and then proceed toexecution block 1015.

IVM sub-routine 1000 may provide a token set obtained from remote IVMdata update sub-routine 700 to a data communication address associatedwith the user identifier (e.g. the data communication address for mobileclient device 200B) at execution block 1015.

IVM sub-routine 1000 may generate an identity verification script 1100,described below with reference to FIG. 11, at execution block 1018. Thecontent of the identity verification script may vary depending on themanual verification flag value.

IVM sub-routine 1000 may return the identity verification script, tokenset, and public encryption key at return block 1099.

Exemplary Identity Verification Script

FIG. 11 illustrates an exemplary identity verification script 1100.Identity verification script 1100 may represent a portion of thefunctionality of IVM service 325A being executed by central processingunit 203A of arbitrary client device 200A in cooperation with variousother hardware and software components of the present methods andsymptoms.

Identity verification script 1100 begins at starting block 1101.

At decision block 1103, if a mobile client device is detected via apersonal area network, then identity verification script 1100 mayproceed to execution block 1104; otherwise identity verification script1100 may proceed to return block 1198.

Identity verification script 1100 may provide the encrypted challengetoken and an identity verification sub-script 1200, described below withreference to FIG. 12, to the mobile client device at execution block1104.

At decision block 1105, if an encrypted token has been obtained from themobile client device responsive to identity verification sub-script1200, then identity verification script 1100 may proceed to return block1199; otherwise identity verification script 1100 may proceed todecision block 1108.

At decision block 1108, if a predefined timeout value for obtaining anencrypted token from mobile client device 200B responsive to identityverification sub-script 1200 has been exceeded, then identityverification script 1100 may proceed to return block 1198; otherwiseidentity verification sub-routine 900 may loop back to decision block1105.

Identity verification script 1100 may return a null value at returnblock 1198.

Identity verification script 1100 may return the encrypted token atreturn block 1199.

Exemplary Identity Verification Sub-Script

FIG. 12 illustrates an exemplary identity verification sub-script 1200.Identity verification sub-script 1200 may represent a portion of thefunctionality of IVM service 325A being executed by central processingunit 203B of mobile client device 200B in cooperation with various otherhardware and software components of the present methods and symptoms.

Identity verification sub-script 100 begins at starting block 1201.

At decision block 1203, if a token set has been obtained from IVM server300A, then identity verification sub-script 1200 may proceed toexecution block 1205.

Identity verification sub-script 1200 may decrypt the challenge tokenobtained from arbitrary client device 200A at execution block 1205.

At decision block 1208, if the decrypted challenge token matches thechallenge token obtained from IVM server 300A, then identityverification sub-script 1200 may proceed to decision block 1210;otherwise identity verification sub-script 1200 may proceed to returnblock 1298.

At decision block 1210, manual verification flag value is true, thenidentity verification sub-script 1200 may proceed to execution block1215; otherwise identity verification sub-script 1200 may proceed toexecution block 1213.

Identity verification sub-script 1200 may decrypt the verification tokenobtained from IVM server 300A at execution block 1213 and then proceedto return block 1299.

Identity verification sub-script 1200 may provide a manual prompt, e.g.via display 215B, at execution block 1215.

At decision block 1218, if a response to the manual prompt has beenobtained, e.g. via user input 213A, then identity verificationsub-script 1200 proceed to decision block 1220.

At decision block 1220, if the obtained response is affirmative, thenidentity verification sub-script 1200 may proceed to execution block1223; otherwise identity verification sub-script 1200 may proceed toreturn block 1298.

Identity verification sub-script 1200 may decrypt the manualverification token obtained from IVM server 300A with the private keyalso obtained from the IVM server at execution block 1223.

Identity verification sub-script 1200 may return an identityverification fail value to identity verification script 1100 at returnblock 1298.

Identity verification sub-script 1200 may return the decryptedverification token (or the decrypted manual verification token) toidentity verification script 1100 at return block 1299.

CONCLUSION

Although specific embodiments have been illustrated and describedherein, a variety of alternate and/or equivalent implementations may besubstituted for the specific embodiments shown and described withoutdeparting from the scope of the present disclosure. This application isintended to cover any adaptations or variations of the embodimentsdiscussed herein.

I claim:
 1. A multifactor authentication system, for authorizing accessa first client device to access a secure resource stored on a webserver, the system comprising: a computer processing unit in datacommunication with said data store; and memory in data communicationwith said computer processing unit and including instructions forcausing said processing unit to execute a first method, said firstmethod including: a) obtaining an identification verification requestfrom the web server, said identification verification request includinga user identifier; b) obtaining a data communication address associatedwith a second client device, said second client device being associatedwith said user identifier; c) selecting a challenge token and averification token; d) providing, to said data communication address, afirst copy of said challenge token and a first copy of said verificationtoken to said data communication address; e) providing, to the webserver, a second copy of said challenge token and a second copy of saidverification token and instructions for causing the web server toexecute a second method, said second method including: 1) providing, tosaid first client device, said second copy of said challenge token andinstructions for causing said first client device to execute a thirdmethod, said third method including: A) determining said second clientdevice is in physical proximity to said first client device; B)providing, to said second client device, said second copy of saidchallenge token and instructions for causing said second client deviceto execute a fourth method, said fourth method including:  i)determining said second copy of said challenge token matches said firstcopy of said challenge token; and  ii) providing, to said first clientdevice, said first copy of said verification token; C) obtaining, fromsaid second client device, said first copy of said verification token;and D) providing said first copy of said verification token to the webserver; 2) obtaining said first copy of said verification token fromsaid first client device; 3) determining said first copy of saidverification token matches said second copy of said verification token;and 4) authorizing said first client device to access to the secureresource.
 2. The multifactor authentication system of claim 1, whereinsaid first client device and said second client device are in datacommunication with one another via a personal area network.